MBMS (Multimedia Broadcast/Multicast Service) is a feature in 3GPP networks that enables the provision of services through multicast/broadcast transmission over 3G networks. This helps to save network resources when a large number of users are interested in the same service at the same time (for example, as in MobileTV). Saving of resources is achieved because the same multicast/broadcast transmission can be received by several users, and the amount of network resources used is not dependent on the number of receivers, which is the case for unicast services.
Multimedia broadcast/multicast services have become widespread, even more so since mobile handheld devices have become capable of receiving multimedia content via radio networks.
The introduction of the Multimedia Broadcast Multicast Service (MBMS) [3GPP-23246-720-MBMS-architecture, 3GPP-22146-820-MBMS-stage1, 3GPP-25346-730-MBMS-stage2] in the UMTS Terrestrial Radio Access (UTRA) provides techniques for optimized transmission of a MBMS bearer service such as point-to-multipoint transmission, selective combining and transmission mode selection between Point-to-Multipoint (PTM) and Point-to-Point (PTP) bearers. MBMS logical transmission channels are defined and are mapped to physical ones. The basic logical channels are as follows:                (a) MBMS point-to-multipoint Control Channel (MCCH): This logical channel is used for a PTM downlink transmission of control plane information between network and User Equipments (UEs).        (b) MBMS point-to-multipoint Traffic Channel (MTCH): This logical channel is used for a PTM downlink transmission of user plane information between network and UEs.        (c) MBMS point-to-multipoint Scheduling Channel (MSCH): This logical channel is used for a PTM downlink transmission of MBMS service transmission schedule between network and UEs.        
As is illustrated schematically in FIG. 1 of the accompanying drawings, the MBMS architecture is divided vertically into two layers according to their functionality: an MBMS bearer service layer 14 and an MBMS user service layer 12. A key node in MBMS is the BM-SC (Broadcast/Multicast Service Center) 4, which transmits MBMS service data towards the UE (User Equipment) 2. The BM-SC 4 is located behind the GGSN (Gateway GPRS Support Node) 10. The UE 2 is in communication with the GGSN 10 via the Radio Access Network (RAN) 6 and the Serving GPRS Support Node (SGSN) 8.
The MBMS user service layer 12 is defined between the BM-SC 4 and the UE 2. MBMS user service (specified in TS 23.346; Multimedia Broadcast/Multicast Service (MBMS); Protocols and codecs consists of the actual content of the MBMS service (e.g. a MobileTV program) and related protocols and codecs and so on.
MBMS security (see TS 33.246; MBMS security; http://www.3gpp.org/ftp/Specs/html-info/33246.htm) is also defined to be at the MBMS user service layer 12. It defines the security functionalities, which can be used to restrict the service only to authorized users.
The MBMS bearer service 14 (see TS 23.246; MBMS bearer service; http://www.3gpp.org/ftp/Specs/html-info/23246.htm) provides the multicast/broadcast transmission infrastructure and resources over which the MBMS user services are transmitted, e.g. the multicast/broadcast distribution tree. In addition to the UE 2 and BM-SC 4, the GGSN 10, SGSN 8 and RAN 6 are part of the MBMS bearer service 14.
The MBMS bearer service 14 is further divided into two modes: multicast mode and broadcast mode. The difference between these two modes is broadly as follows.
Multicast mode services are only transmitted in those areas where interested UEs 2 are present. When a UE 2 wants to receive a MBMS service which is provided using multicast mode, the UE 2 sends an IGMP (Internet Group Management Protocol) join request to the GGSN 10 over the default PDP (Packet Data Protocol) context. This will result in a MBMS UE context being created to each network node on the path between and including the UE 2 and the BM-SC 4, and the multicast distribution tree is updated accordingly (see clause 8.2 of TS 23.246). In short, the network is aware of the UE on MBMS bearer level.
In general, broadcast mode services are transmitted in certain areas regardless of whether or not UEs 2 are present. When a UE 2 wants to receive a MBMS service which is provided using broadcast mode, the UE 2 configures itself locally to receive the transmission and does not contact the network on the bearer level (see clause 8.12 of TS 23.246). In short, the network is not aware of the UE 2 on the MBMS bearer level.
MBMS security is independent of multicast and broadcast modes as it is MBMS user service level 12 functionality. This means that both multicast mode and broadcast mode services can be protected using MBMS security. When a UE 2 wants to receive a protected service, then the UE 2, in addition to bearer level actions described above, registers to the BM-SC 4 on the MBMS user service layer 12 to get the needed MBMS service keys.
In MBMS security, the UE 2 uses a PDP context (PDP context provides IP connectivity for the UE 2) for registering to and de-registering from the MBMS user service. The same PDP context is also used by the BM-SC 4 to push MBMS service key (MSK) update messages to the UE 2. This is possible since the BM-SC 4 stores the IP address of the UE 2 when it receives a registration message from the UE 2 on the PDP context. This is depicted schematically in FIG. 2 of the accompanying drawings.
As appreciated by the present applicant, a situation can arise in which the PDP context is deleted (or replaced by another PDP context) for some reason, and this would mean that the associated IP address of the UE 2 would no longer be valid, as is represented schematically in FIG. 3 of the accompanying drawings.
However, the BM-SC 4 would not know that the IP address is no longer valid, and would continue sending MBMS service key (MSK) messages to the non-existing IP address. The MSK messages would be discarded in the GGSN 10 as the GGSN 10 would not recognize the destination IP address in the message.
Possible reasons for the PDP context being deleted or replace are found in TS 24.008 ch. 6.1.3.4.2: “regular deactivation”, “network failure”, “Operator Determined Barring”, or “reactivation requested”. The user might not notice the deletion or replacement as the PDP context is used only for background key management and the actual MBMS content is sent over the MBMS bearers.
As a result, the UE 2 might not receive the MBMS service keys in time, these service keys being required to decrypt the service, or the MBMS service key messages could be sent to the wrong UE 2 if the IP address was quickly allocated to another UE 2 (sending the service keys to the wrong UE would not break MBMS security, since the service keys are encrypted with UE-specific higher layer keys).
The current security specification (TS 33.246) states that the UE 2 may notice from the key identifiers of the received MBMS content that it does not have the correct MSK to decrypt the service. This can trigger the UE 2 to fetch a new MSK from the BM-SC 4. To do this, the UE 2 would have to set up a new PDP context if the UE 2 does not have any active PDP contexts. The problem with this mechanism is that the UE 2 may already have received some real-time content encrypted with the missing MSK. This would mean that there is a service interruption (e.g. in mobile TV program) until the UE 2 has fetched and installed the correct MSK.
Currently, the loss of the PDP context has been addressed differently for multicast mode and broadcast modes.
The current approach for the multicast mode will first be described. In this scenario, as defined in TS 23.246 clause 6.1, the UE 2, SGSN 8, GGSN 10 and BM-SC 4 have stored the UE specific MBMS UE context needed to establish the multicast distribution tree. This MBMS UE context is set up with the MBMS bearer level activation procedure.
In addition, the UE 2 and SGSN 8 have stored the association between the PDP context (so called linked NSAPI or Network layer Service Access Point Identifier) and the MBMS UE context, as illustrated schematically in FIG. 4 of the accompanying drawings.
If the PDP context is deleted by the UE 2, SGSN 8 or GGSN 10, then the SGSN 8 will start a multicast service deactivation procedure to delete the MBMS UE context in all nodes (see clause 8.7 of TS 23.246).
This multicast service deactivation procedure will also reach the BM-SC 4, which will then know that the MBMS bearer service (and MBMS UE context) has been deactivated for this UE 2 and the BM-SC 4 will then assume that the MBMS user service related to the deactivated MBMS bearer service is also deactivated for this UE 2. The BM-SC 4 then knows that it should no longer send MBMS service key update messages to the UE 2.
The multicast service deactivation procedure will also reach the UE 2 and the user would likely notice that the MBMS service went down. This would of course mean service interruption. The user might then re-initiate the MBMS user service (which would then mean activating a new PDP context and activating MBMS bearer service again).
Turning now to the current approach for the broadcast mode, the issue for the broadcast mode is different as the network is not aware of the UE 2 at the MBMS bearer level, since there are no UE specific MBMS UE contexts stored in the SGSN 8, GGSN 10 or BM-SC 4. Therefore the network does not know that a certain PDP context is used for MBMS key management. Two different cases need to be considered: (a) UE-initiated PDP context deletion; and (b) network-initiated PDP context deletion.
The UE-initiated PDP context deletion case is already covered in clause 6.3.2.1A of TS 33.246, which states that the UE 2 shall not delete the PDP context (used for key management) until the UE 2 has de-registered from the MBMS user service. It has also been stated in 6.3.1 of TS 33.246 that the PDP context should be of interactive or background QoS (Quality of Service) class, which are known to be long-lived. (It is still to be decided if the PDP context could still be deleted by accident, e.g. by user actions.)
However, the network-initiated PDP context deletion is not covered in the current specifications. Although the PDP context could be long-lived, it may still be possible that the PDP context is deleted by the network, i.e. SGSN 8 or GGSN 10 for some reason, e.g. network failure. In this case, the BM-SC 4 will not be aware of that the UE IP address is no longer valid and it would continue sending MBMS service key (MSK) messages to a non-existing IP address, as is represented in FIG. 3 and described above. This is a problem because, in the broadcast mode, the intermediate nodes (i.e. the SGSN 8 and GGSN 10) are not aware that the deleted PDP context was used for MBMS, so they cannot indicate this to BM-SC 4 either. As a consequence, the UE 2 would not receive the required keys in time and the service would be interrupted for the UE 2 as it cannot decrypt the MBMS user service.
It is desirable to address this issue.
WO 99/48246 discloses a scheme for re-establishing a lost multicast connection between an end user and a group in a multicast environment.